IBM DB2 предоставляет возможности построения систем высокоготовных отказоустойчивых систем (High Availability Disaster Recovery) начиная с самых младших редакций сервера , включая DB2 Express-C FTL. Все эти возможности в документации и книгах по DB2 скрываются за аббревиатурой "HADR". В данной статье будет рассказано о том, как можно штатными средствами DB2 настроить отказоустойчивую конфигурацию, в которой при сбое в работе основного сервера с базой данных можно в течение нескольких секунд переключить работу системы на резервный сервер СУБД.
IBM DB2 предоставляет возможности построения систем высокоготовных отказоустойчивых систем (High Availability Disaster Recovery) начиная с самых младших редакций сервера , включая DB2 Express-C FTL. Все эти возможности в документации и книгах по DB2 скрываются за аббревиатурой "HADR".
Естественно, что в документации по DB2 есть исчерпывающая информация по возможностям конфигурирования HADR. Но есть и отдельный Redbook (на английском) "High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows", подробно рассматривающий данные вопросы, и имеющий, на мой взгляд, более удачную структуру информации.
В данной статье будет рассказано о том, как можно штатными средствами DB2 настроить отказоустойчивую конфигурацию, в которой при сбое в работе основного сервера с базой данных можно в течение нескольких секунд переключить работу системы на резервный сервер СУБД.
О чем в этой статье НЕ БУДЕТ рассказано.
1. Здесь вы не найдете описания окон графического интерфейса для настройки и конфигурирования HADR. Графический интерфейс пользователя для управления и настройки HADR есть. Перейти на него можно по правому щелчку мышки на имени базы данных в Центре управления DB2. Но прочитав эту статью вы будете лучше понимать, что вы делаете в рамках графического интерфейса.
2. Здесь вы не найдете рецептов настройки автоматического переключения между узлами HADR кластера. Для этого может быть использовано различное кластерное ПО, например IBM Tivoli. Об этом вы можете прочитать в упомянутом Redbookе (главы 7 и 8) и документации по DB2. В рамках данной статьи будет рассказано, как переключить узлы кластера вручную.
3. В данной статье не рассматриваются различные сценарии восстановления работоспособной конфигураци после сбоя. Например в Reedbooke данным вопросам посвящены 7 страниц раздела 3.4.5.
4. Обсуждение вопросов администрирования конфигураций HADR также вынесено за рамки данной статьи. Подобные вопросы подробно изложены в документации по DB2 и.... да, в Redbookе
5. Вопросы лицензирования HADR конфигураций подробно рассмотрены в статье , опубликованной на developerWorks. к сожалению, пока на английском языке.
Для того, чтобы восползоваться HADR вам необходимо иметь коммерческую версию DB2 (или ее trial-версию). В настоящий момент для целей изучения возможностей DB2 HADR рекомендуется использовать DB2 v9.7 FP1.Скачать ее можно с сайта IBM. Официально данная версия на данный момент не рекомендована, но все исправления, что есть в сборке v9.5 22521 в нее включены.
При установке DB2 Server FixPack устанавливается trial-версия с ограниченным сроком действия.
DB2 High Availability Disaster Recovery (HADR) - это режим репликации данных, обеспечивающий режим выской доступности решения при частичном и/или полном отказе рабочего узла.
При стандартных подходах восстановление после сбоя в работе сервера, где расположена база данных, может потребовать перезагрузки сервера и с последующим восстановлением базы данных, что вызовет простой системы в целом. Использование DB2 HADR позволяет безболезненно сократить общее время простоя системы всего лишь до нескольких секунд. HADR обеспечивает сохранность данных за счет постоянной репликации изменений в основной базе (PRIMARY) в резервную (STANDBY), которая становится основной в случае сбоя. Изменения передаются в виде записей транзакционного журнала, которые, в свою очередь, резервный сервер "накатывает" на свою копию базы данных, обеспечивая тем самым, синхронность данных с основным сервером. При этом приложения всегда работают с основным сервером, а соединение с резервным запрещено (в ближайшем будущем планируется обеспечение режима доступа "только для чтения" для резервной базы данных). Поскольку взаимодействие в рамках HADR осуществляется по протоколу TCP/IP, то резервный сервер может быть развернут на удаленном узле, что поволяет обеспечить сохранность данных даже в случае физического разрушения основного узла (т.н. катастрофо-устойчивая конфигурация).
В общем виде устройство HADR в DB2 показано на рисунке ниже.
Передача между основным и резервным сервером HADR данных, включая сигналы готовности и управляющую информацию о состоянии репликации, происходит по выделенному порту TCP/IP, причем номер этого порта отличен от номера порта, на котором работает сам экземпляр DB2. Единственный доступный режим конфигурации - в котором присутствуют 2 узла - основной и резервный. Построить топологию с нескоклькими резервными серверами в данном случае не получится. НО!
Поскольку HADR-репликация осуществляется на уровне базы данных, а не экземпляра DB2, то на "большом" сервере могут быть сосредоточены несколько первичных баз, а вот резервные базы, могут быть разнесены на несколько физических серверов. Причем для одной базы сервер может быть первичным, а в другом случае - вторичным (Database A,C на рисунке ниже)
При этом для каждой базы данных на первичном сервере надо задавать свой собственный порт, который будет использоваться для репликации.
В рамках HADR можно использовать три уровня защиты от потенциальной потери данных, выбирая один из трех режимов синхронизации:
Синхронный (Synchronous):
Запись в транзакционный журнал считается успешной в том случае, когда буфер журнала был записан на диск на основном сервере и получено уведомление, что он также был записан в транзакционный журнал на резервном сервере. В данном режиме потеря данных невозможна, если узлы находятся в состоянии Peer.
Почти синхронный (Near-synchronous):
Этот режим используется по-умолчанию. Запись в транзакционный журнал считается успешной в том случае, когда буфер журнала был записан на диск на основном сервере и получено уведомление, что он был полулчен резервным сервером.
Асинхронный (Asynchronous):
Запись в транзакционный журнал считается успешной в том случае, когда буфер журнала был записан на диск кна основном сервере и получено уведомление, что он был передан на резервный сервер.В данном режиме возможна потеря данных.
База данных называется 'hadrdb'
Бесплатная DB2 Express-C не обладает лицензией, позволяющей строить HADR конфигурации. Поэтому для проверки возможностей HADR потребуется наличие либо FTL лицензии на DB2 Express-C, либо редакции Workgroup или Enterprise, оценочные версии которых можно скачать с сайта IBM. В настоящий момент из публично доступных версий рекомендуется использовать DB2 v9.5 FixPack 4. Также следует отметить, что среди публично доступных версий DB2 нет версии, которая может рабтать с платформой 1С:Предприятия 8.2. Ее появление планируется с выходом FP1 для DB2 v9.7.
Прежде, чем приступить к конфигурированию HADR, убедитесь, что версии DB2 у вас одинаковые на основном и резервном серверах. Основной и резервный сервер должны работать на одной и той же ОС, иметь одинаковую разрядность, и версии DB2 должны совпадать.
По-умолчниаю базы создаются с циклическим транзакционным жунранлом. Для HADR необходимо переключить нашу базу данных на архивный режим журналирвания с циклического журналирования.
Чтобы включить данный режим журналирования, надо хотя бы одному из двух параметров LOGARCHMETH1 или LOGARCHMETH2 задать значение, отличное от OFF.
В качестве значения параметра указывается место размещения архивов транзакционнного журнала базы данных. Причем если вы зададите значение для обеих параметров, то у вас будет создаваться 2 копии архивов транзакционного журнала, но расположены они будут в разных местах.
Более подробно о параметрах конфигурации журнала транзакций при HADR можно прочитать в документации по DB2.
Методов создания начальной копии резервной базы несколько. Вы можете ознакомиться с ними в документации по DB2. Здесь же приведен самый простой метод - через восстановление резервной копии.
Сделайте offline резервную копию вашей основной базы, выполнив команду
Копировать в буфер обменаdb2 backup db hadrdb to <dir>
Скопируйте файл бэкапа на резервный сервер.
Создайте новую базу из резервной копии выполнив команду
Копировать в буфер обменаdb2 restore db hadrdb from <dir>
Если у вас конфигурация дисков/файловой системы не совпадает с основным сервером, то требуется при создании базы данных из резервной копии добаваить параметры ON <PATH> DBPATH ON <PATH>.
Например, если у вас на основном сервере база размещается на диске E:, а на резервном есть только С:, то команда будет выглядеть следующим образом
Копировать в буфер обменаdb2 restore db hadrdb from <dir> on E: dbpath on E:
также не забудьте в данном случае про параметры LOGARCHMET1/2! Возможно их тоже следует поправить в соответствии с реалиями резервного сервера и его файловой системы.
В случае HADR рекомендуется задать следующие значения параметров конфигурации базы данных.
| Параметр базы данных | Значение |
|---|---|
| LOGINDEXBUILD | ON |
| INDEXREC | RESTART |
Если вы хотите подробней познакомиться с рекомендациями по установке этих параметров, отвечающих за синхронизацию индексов, их можно найти в документации по DB2, Для целей настоящей статьи мы ограничимся лишь перечислением задаваемых значений.
Для каждой копии базы данных (основной и резервной) необходимо задать следующие параметры конфигурации:
Таким образом конфигуация баз данных на серверах будет выглядеть следующим образом
| Параметр базы данных | Значение |
|---|---|
| HADR_SYNCMODE | Режим синхронизации. ASYNC, NEARSYNC, SYNC. Мы их вкратце рассмотрели в разделе "Режимы синхронизации HADR" |
| HADR_TIMEOUT | Время ожидания ответа от основного сервер в секундах. |
| HADR_LOCAL_HOST | Имя/адрес локального сервера |
| HADR_LOCAL_SVC | Номер локального порта (имя сервиса), используемого для HADR |
| HADR_REMOTE_HOST | Имя/адрес удаленного сервера |
| HADR_REMOTE_SVC | Номер порта, используемого для HADR на удаленном сервере |
| HADR_REMOTE_INST |
Имя экзеспляра DB2 на удаленном сервере. Имя экземпляра можно узнать выполнив команду db2level, в выводе которой в первой строке присутствует данная информация. В примере ниже имя инстанса db2inst. DB21085I Instance "db2inst" uses "64" bits and DB2 code release "SQL09052" |
Первые 2 параметра будут одинаковыми на обеих серверах А последующие 5 зеркально меняются при конфигурировании основного и резервного серверов Давайте рассмотрим конкретную конфигурацию. Основной сервер IP: 172.17.192.92 Резервный сервер IP: 172.17.192.193 Имя инстанса на обоих серверах - "DB2" HADR порт тоже будем использовать один и тот же - 51000 Таким образом конфигуация баз данных на серверах будет выглядеть следующим образом
| Параметр базы данных | Основной |
Резервный |
|---|---|---|
| HADR_SYNCMODE | SYNC |
SYNC |
| HADR_TIMEOUT | 120 | 120 |
| HADR_LOCAL_HOST | 172.17.192.92 | 172.17.192.193 |
| HADR_LOCAL_SVC | 51000 | 51000 |
| HADR_REMOTE_HOST | 172.17.192.193 | 172.17.192.92 |
| HADR_REMOTE_SVC | 51000 | 51000 |
| HADR_REMOTE_INST | DB2 | DB2 |
Конфигурация альтернативного сервера.
Также для каждого из серверов необходимо укзать имя/адрес и порт альтернативного сервера, к которому будут подключаться клиенты в случая сбоя.
Конфигурирование выполняется командойна стороне, где установлен сервер 1С:Предприятия.
Копировать в буфер обменаdb2 update alternate server for database hadrdb using hostname <host|IP> port <port>
Это мы сконфигурировали альтернативный, а где-же основной? Как правило, сервер 1С совмещен с сервером баз данных, а значит запись об основном сервере базы данных присутствует на сервере. Посмотреть спискок всех каталогизированных баз данных можно командой
Копировать в буфер обменаdb2 list db directory
Вот пример каталожной записи о базе данных
Копировать в буфер обменаDatabase 1 entry: Database alias = NEWDB2 Database name = NEWDB2 Local database directory = /home/db2inst Database release level = c.00 Comment = Directory entry type = Indirect Catalog database partition number = 0 Alternate server hostname = Alternate server port number =
Как видите, для нее не задано имя и порт альтернативного инстанса сервера DB2, где находится резервная копия базы.
Но что делать, если вы видим такую картину?
Копировать в буфер обменаC:\IBM\SQLLIB\BIN>db2 list db directory SQL1057W The system database directory is empty. SQLSTATE=01606
И это вполне возможно, если сервер 1С и сервер базы данных разнесены. Дело в том, что 1С создает каталожную запись только на момент создания базы данных, а потом ее удаляет, т.к. для механизма соединения, который использует 1С, эта каталожная запись о базе данных не нужна. Но нам придется ее воссоздать для того, чтобы иметь возможность задать альтернативный сервер для базы данных. Это можно сделать через Центр Управления DB2, а можно сделать гороздо быстрей в командной строке. Во-первых, нам надо каталогизировать удаленный узел (инстанс) DB2, а потом в рамках этого узла каталогизировать базу данных. Рассмотрим на примере, что скрывается за всеми этими словами. Есть сервер базы данных, расположенный на машине с адресом 172.17.192.92. Инстанс DB2 называется 'DB2' и работатет по стандартному порту 50000.
Вначале мы делаем каталожную запись об узле
Копировать в буфер обменаdb2 catalog tcpip node MYNODE remote 172.172.192.92 server 50000 remote_instance DB2
После этого мы каталогизируем базу данных в рамках этого узла
Копировать в буфер обменаdb2 catalog database HADRDB at MYNODE
после этого можно проверить соединение с базой командой
Копировать в буфер обменаdb2 connect to HADRDB user db2admin
Теперь осталось только указать альтернативны сервер. Посольку при каталогизации базы мы указали основной сервер с адресом *.92, то в качестве альтернативного задаем *.193
Копировать в буфер обменаdb2 update alternate server for database HADRDB using hostname 172.17.192.193 port 50000
После чего еще раз можно выполнить команду db2 list db directory и убедится, что для базы данных задан альтернативный сервер.
Порядок запуска HADR предусматривает вначале запуск резервного сервера, а потом основного. Для запуска базы данных в режиме HADR на резервном сервере HADR выполняется команда
Копировать в буфер обменаdb2 start hadr on db hadrdb as standby
Для запуска базы данных в режиме HADR на основном сервере hadr выполняется команда
Копировать в буфер обменаdb2 start hadr on db hadrdb as primary
Перед каждой из этих команд желательно выполнить деактивацию базы данных, чтобы убедится, что база данных перед запуском была неактивна.
Копировать в буфер обменаdb2 deactivate db HADRDB
Как убедиться в том, что HADR-пара работает? Эту информацию можно поулчить, сделав снимок базы данных (database snapshot), в результатах которого соддержится информация о HADR статусе.
Копировать в буфер обменаdb2 get snapshot for database on HADRDB
Ниже приведен вывод HADR статуса для резервной копии базы, сразу после запуска HADR.
Копировать в буфер обменаHADR Status Role = Standby State = Remote catchup pending Synchronization mode = Nearsync Connection status = Disconnected , 14.07.2009 02:46:28.061372 Heartbeats missed = 0 Local host = 172.17.192.193 Local service = 51000 Remote host = 172.17.192.92 Remote service = 51000 Remote instance = DB2 timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000000.LOG, 0, 00000001662AD2A1 Standby log position(file, page, LSN) = S0000075.LOG, 6829, 00000001662AD2A1 Log gap running average(bytes) = 0
А вот HADR статус основной копии базы, сразу после запуска
Копировать в буфер обменаHADR Status Role = Primary State = Peer Synchronization mode = Nearsync Connection status = Connected , 14.07.2009 02:55:57.155230 Heartbeats missed = 0 Local host = 172.17.192.92 Local service = 51000 Remote host = 172.17.192.193 Remote service = 51000 Remote instance = DB2 timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000 Standby log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000 Log gap running average(bytes) = 1116434
В рабочем состоянии статус HADR-пары должен быть "Peer".
Еще раз сделаем снимок реервной базы, после того как HADR был активирован на обоих узлах пары, и убедимся, что узел также находится в рабочем состоянии
Копировать в буфер обменаHADR Status Role = Standby State = Peer Synchronization mode = Nearsync Connection status = Connected , 14.07.2009 02:54:35.389333 Heartbeats missed = 0 Local host = 172.17.192.193 Local service = 51000 Remote host = 172.17.192.92 Remote service = 51000 Remote instance = DB2 timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000 Standby log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000 Log gap running average(bytes) = 279108
Обратите внимание на последнюю строчку статуса. Оказывается наши копии на момент запуска были не совсем синхронны. В данном случае возникает разница в логах, которая со временем снижается до 0, по мере репликации транзакционного журнала на резервную копию базы данных.
Если вы хотите остановить HADR операции, то рекомендуется следующая последовательность операций для остановки HADR-пары:
1. Деактивировать основную базу данных.
2. Деактивировать резервную базу данных.
Выполняется эта оуперация уже знакомой командой
Копировать в буфер обменаdb2 deactivate db HADRDB
Также можно выполнить остановку HADR режима на основной базе командой
Копировать в буфер обменаdb2 stop hadr on db HADRDB
(На резервной базе такая команда приведет к ошибке!) В данном случае основная база переходит в стандартный режим работы. Причем после повторного запуска основной базы в режиме HADR, изменения, сделанные за период работы в стандартном режиме, будут синхронизированы с резервной копией базы данных.
Вообще для HADR пары есть 3 основных операции: START, STOP и TAKEOVER. Один из переводов слова "takeover" означет "взятие под свой контроль и управление". Как делается запуск, мы уже знаем.
Если вы хотите остановить HADR операции, то рекомендуется следующая последовательность операций для остановки HADR-пары:
1. Деактивировать основную базу данных.
2. Деактивировать резервную базу данных.
Выполняется эта операция уже знакомой командой
Копировать в буфер обменаdb2 deactivate db HADRDB
Также можно выполнить остановку HADR режима на основной базе командой
Копировать в буфер обменаdb2 stop hadr on db HADRDB
(На резервной базе такая команда приведет к ошибке!) В данном случае основная база переходит в стандартный режим работы. Причем после повторного запуска основной базы в режиме HADR, изменения, сделанные за период работы в стандартном режиме, будут синхронизированы с резервной копией базы данных, если для пары режим HADR Синхронный или Почти синхронный режим работы.
При помощи команды
Копировать в буфер обменаdb2 TAKEOVER HADR ON DB HADRDB [BY FORCE]
вы можете поменять ролями основную и резервную копию базы, если они находятся в состоянии "Peer". Если же произошел сбой в работе основной базы, то для перевода резервной базы в состояние основной, необходимо добавить параметр команды BY FORCE. Причем, рекомендуется убедиться, что основная база данных не обслуживает запросы. Возможно для этого будет недостаточно команды db2stop, а потребуются системные средства управления.
Если произошел отказ основной базы данных, то пользователь 1С получит ошибку соединения с базой. При перезапуске он автоматически будет подключен к резервному серверу с базой данных (к тому моменту он должен быть переведен в режим primary естественно). Поскольку рабочий процесс сервера 1С держит пул соединений с базой, то многие пользователи просто не заметят отказа основного сервера, посольку "подхватят" уже рабочее соединение с резервным сервером.